A. Field of the Invention
The present invention relates generally to data processing systems and, more particularly, to providing secure communication between a client and a server.
B. Description of the Related Art
The Internet is a collection of computers sending messages to one another over a network that delivers the messages. There are, however, fraudulent computers on the Internet that attempt to trick the network into delivering messages intended for another to them or instruct the network to send bogus messages. In addition, information on the network could be viewed as it is being delivered. Therefore, there is a need to authenticate that the sender or recipient of the message is a proper sender or recipient and to encrypt the message to prevent unauthorized viewing.
When starting a secure communication session, the sender asks a recipient to begin a communication session, and the recipient replies with information that the sender can use to verify that the recipient is not fraudulent. In some cases, the sender could also provide information that the recipient can use to verify that the sender is not fraudulent.
After confirmation of the identity of the recipient and possibly the sender, the sender and the recipient negotiate a set of xe2x80x9ckeysxe2x80x9d with which to use to encrypt and decrypt messages sent between them.
When encrypting a message, the sender uses an encryption key and an encryption algorithm to encrypt messages so that those without the appropriate key cannot read the messages. Upon receiving an encrypted message, the recipient decrypts messages using the appropriate key to render the messages readable (which is also known as xe2x80x9ccleartextxe2x80x9d).
Various publicly available systems permit the authentication, encryption, and decryption of messages from one end to another end on the Internet. Most web-based applications, such as on-line banking, electronic shopping, and secure remote access to protected networks (like Intranets), use an end-to-end security protocol, such as the Secure Session Layer (SSL) protocol or Transport Layer Security (TLS) protocol for their security needs. Some end-to-end security protocols, such as SSL and TLS, use public-key cryptography to generate symmetric keys (which are also known as session keys) that are used by the encryption and authentication algorithms. The sender and receiver negotiate the symmetric keys during a xe2x80x9chandshakexe2x80x9d protocol, which typically includes the following steps: (1) authentication, and (2) key exchange using a Rivest, Shamir, and Adelman (RSA) or a Diffie-Hellman (DH) algorithm.
FIG. 1 illustrates a high level diagram of how clients 100 would communicate with a server 120 over a network, such as the Internet, in a manner consistent with the prior systems. The term xe2x80x9cclientxe2x80x9d is typically associated with a program that sends a request for information from the xe2x80x9cserver.xe2x80x9d Nevertheless, these terms are used as examples to differentiate the end points in a network, and xe2x80x9cclientxe2x80x9d could mean xe2x80x9cserverxe2x80x9d and vice versa.
Clients 100 attempt to negotiate how information should be securely transmitted. This negotiation is referred to as a handshaking session. For example, a client 100 desiring to initiate a link 110 using SSL (because of the relatedness between SSL and TLS, in the following discussions xe2x80x9cSSLxe2x80x9d should be regarded as xe2x80x9cSSL or TLSxe2x80x9d) and RSA key exchanges would extend its xe2x80x9chandxe2x80x9d by informing server 120 it wishes to communicate using SSL and provide information about the client. Server 120 would extend its xe2x80x9chandxe2x80x9d with a reply containing information about server 120 and a certificate used in authenticating the server. In some applications, the server may wish to authenticate client 100, for example if a user of client 100 is accessing a bank account. If so, server 120 would ask for the certificate of client 100. Another method of authenticating the client would be to provide an application-specific authentication at a level above the SSL layer. For example, the user could supply an authentication token, such as a password, known to the server. Client 100 then authenticates server 120 using the certificate and other information, suchan Internet address. If server 120 cannot be authenticated, the user of client 100 is warned of the problem and informed that an encrypted and authenticated connection cannot be established. Otherwise, client 100 generates a premaster secret, encrypts it with a public key of server 120, which is a part of the certificate of server 120, and sends the encrypted result to server 120. The premaster secret is a secret message that is used to derive a master secret by including additional information such as random numbers selected by the client and server. When an RSA key exchange mechanism is used, client 100 selects the premaster secret without any input from server 120. By including an additional hashing step in the derivation of the master secret from the premaster secret, server 120 can supply input in the master secret derivation. When client authentication is requested, client 100 uses a private key of client 100 to sign any piece of data that is unique to this handshake and known by both the client and server, and sends the signed data, the certificate of client 100, and the encrypted premaster secret to server 120. Server 120 then attempts to authenticate client 100.
If all authentications are successful, server 120 generates the premaster secret from the encrypted result sent from client 100. For example, using RSA, the server decrypts the encrypted result from client 100 to generate the premaster secret. In a DH key exchange, server 120 computes the premaster secret using a public key exponentiation. Then, client 100 and server 120 use the premaster secret to generate a master secret, which is used to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to detect any changes in the data between the time it was sent and the time it is received over the SSL connection.
Client 100 sends a message to server 120 informing it that future messages from the client will be encrypted with the session key and an encrypted message indicating that the client portion of the handshake is finished. Server 120 responds with a message to client 100 informing it that future messages from the server will be encrypted with the session key and an encrypted message indicating that the server portion of the handshake is finished.
Thereby, the SSL handshake session is completed and an SSL link 110, over which client 100 and server 120 transfer data, is established. For subsequent communications between client 100 and server 120, a session resumption procedure is initiated. In this case, client 100 simply identifies itself to server 120 and indicates that it will continue to use the agreed upon keys from the previous handshaking session stored in memory in client 100. Server 120 would acknowledge that the end-to-end security session should be resumed over link 110 and use the keys stored in memory in the server 120.
These publicly available systems, however, could be improved.
The number of new secure connections a hyper text transfer protocol secure (HTTPS) server can handle is typically a small fraction of the number of new regular connections (HTTP) it can handle because the computation steps in the handshaking session are computationally intense and burdensome. If another client 100 requests a new secure connection, it must be refused until the server is able to process the request.
Also, the encrypted connection can make troubleshooting problematic. It may be difficult for application users to test their programs and thereby diagnose and understand performance problems, especially when the user cannot monitor performance at end-points (typically browsers or HTTPS servers) either because of lack of access to source code and/or the difficulty of putting in the appropriate instrumentation mechanisms there.
Additionally, the prior systems could send inappropriate information because a user receiving a message from a server may not require all of the information sent or the message may be an undesirable format.
Systems and methods consistent with the present invention can provide a greater number of secure connections between a first computer and a second computer in a given time than was typically possible in the prior art. Also, the systems and methods can place mechanisms to process data in locations within the system that were previously unavailable. Thereby, a secure system could test or reformat the information sent between the first and second computers so that only appropriate information is received.
In accordance with methods consistent with the present invention, a method is provided. This method provides a connection between a first computer and a second computer by receiving, at a third computer, information regarding one of the first and second computers to facilitate establishment of a secure connection between the first computer and the second computer, creating a first end-to-end security link between the first computer and third computer, and creating a second end-to-end security link between the second computer and the third computer to establish the secure connection.
In accordance with systems consistent With the present invention, a system is provided. This system provides a connection between a first computer and a second computer and includes a third computer that receives information regarding one of the first and second computers to facilitate establishment of a secure connection between the first computer and the second computer, a first end-to-end security link between the first computer and third computer, and a second end-to-end security link between the second computer and the third computer to establish the secure connection.
In accordance with devices consistent with the present invention, a computer medium is provided. This computer medium contains instructions for controlling a computer network to perform a method for providing a connection between a first computer and a second computer, the method including receiving, at a third computer, information regarding one of the first and second computers to facilitate establishment of a secure connection between the first computer and the second computer, creating a first end-to-end security link between the first computer and third computer, and creating a second end-to-end security link between the second computer and the third computer to establish the secure connection.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.